-
Notifications
You must be signed in to change notification settings - Fork 10.6k
Fix parameter pack compiler crash related to tuple_pack_element_addr call
#85975
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Fix parameter pack compiler crash related to tuple_pack_element_addr call
#85975
Conversation
slavapestov
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My only concern with this change is that it requires adding the check in four places. Is there a fifth that was missed? Maybe there's a better way to factor this out? If not, that's OK, but someone who understands DI should take a closer look. CC @gottesmm
|
Also this technically changes language semantics, because it precludes the possibility of initializing a tuple like |
|
Here's another patch that addresses several more crashes. I'll open up another PR once we decide that this one is worth merging. |
Full disclosure: This code was almost entirely written by Claude. I ran into a compiler crash, thought I'd have Claude take a crack at fixing it (very skeptical that it would), and as far as I can tell, it has actually fixed the issue.
That said, this is pretty far outside of my area of expertise. If this PR is against contributor guidelines or so bad that it's not at all usable, I will happily close it. I'm not here to take a moral stand on AI. I just want the bug fixed.
I also know my commit messages are lacking. I plan on squashing before I merge.
Issue
The following code causes a compiler crash on the version of Swift that ships with Xcode 26.1. I have confirmed it also crashes when run with the latest
mainbranch by building the compiler locally and using it to execute the repro case.Repro
Crash stack trace
This is from the Swift Development Snapshot on December 1st
Fix
Looks like the issue is that there are some portions of the codebase that don't guard against parameter packs, and therefor treat them as normal, multi-element tuples.
Here's how Claude described the fix (edited for brevity).
Parameter packs have unknown arity at compile time, which breaks the assumptions of the
DefiniteInitialization (DI) pass.
Consider the Codable struct that was crashing:
The tuple
(repeat each Input)could have 0, 1, 5, or any number of elements depending on how it's instantiated:Coder<Int>→ 1 elementCoder<Int, String, Bool>→ 3 elementsCoder<>→ 0 elements (empty pack)DI's element-counting logic (
getElementCountRec) was trying to iterate the tuple's elements and assign fixedindices, but you can't assign static indices to a dynamically-sized structure.
The Solution
Treat the entire pack-expansion tuple as one opaque unit:
This means:
(repeat each Input)tuple as a single "blob"tuple_pack_element_addr(which takes a dynamicindex)
// End Claude explanation
Addendum
This crash is very very particular. The repro case must do all of the following.
Here is as far as I've pared down the crash case